Entities involved in cryptography, science and research, security, military, communications and gaming industry applications, to name a few, all have present and growing needs for “entropy data,” such as that used to stir, disturb or otherwise introduce unpredictability or non-determination into deterministic functions or routines such as computer-generated random numbers. As a practical matter, however, it is well known that obtaining truly random numbers for the above-mentioned and other applications is exceptionally difficult. Also, seed values for pseudo random number generators (PRNGs) must meet precise criteria in order for the PRNG to be of practical use in certain applications, especially those involved in cryptography.
To this end, it has been fairly suggested to develop dedicated computing devices for delivering or introducing entropy data beyond that which is capable of being generated by a single computing device. In U.S. Patent Publication 2006/0072747, for example, multiple “entropy servers” are contemplated and covers the scenario in which a computing device makes a request to the servers using a predetermined protocol over a connection existing solely to service that request. Also, the request is semantically understood by both parties to be, in fact, a request for entropy and the enlisting party awaits responses from the servers over the same connection as that which the request was made.
A problem with this approach, however, is that dedicated systems and protocols add economic and computing costs, which effectively limits growth and somewhat burdens resources. To the extent the choreography between devices also occurs in a predetermined fashion over a dedicated, known connection, this potentially compromises physical security or that from hacking.
In other applications, a typical way of obtaining “entropy bits” for use as seed values in PRNGs (on Linux) is to collect some combination of inter-keystroke timings, mouse-coordinate deltas, and/or inter-interrupt timing values on a local machine. An “entropy buffer,” for the bits, is then persisted to disk across machine reboots and be reused on startup. However, this technique has been criticized in the Linux community, from time to time, not only on information-theoretic grounds (because seed values produced are not random at all) but also because of its vulnerability to hacking. While the rebuttal has been that the heuristics have worked “well enough” in practice, this is insufficient for certain critical applications listed above and in the future as demand for entropy bits grows across all applications.
Furthermore, the Linux entropy scheme is well-known to be a low-yield system, seldom capable of producing more than hundreds of bits per second. Accordingly, it is not unusual for a Linux machine to “starve” for entropy in periods of high demand (when numerous secure connections are being opened or numerous cryptographic applications are executing, for instance). As documented for the Exim utility in Debian: “Insufficient entropy available is a frequent cause of TLS failures in Exim context. If Exim says ‘not enough random bytes available’, or simply hangs silently when an encrypted connection should be established, then Exim was unable to read enough random data from /dev/random to do whatever cryptographic operation is requested.” (http://pkg-exim4.alioth.debian.org/README/README.Debian.html#id2452196). The mere fact that you can starve a Linux machine for entropy in this straightforward way, of course, constitutes a vulnerability.
Accordingly, a need exists in the art of entropy collection for minimizing both economic and computing costs and reducing or eliminating threats or vulnerabilities relating to physical and hacking security. Such should also contemplate a sound information-theoretic basis, enable high yields or payloads, regardless of when needed, be of sufficient quality for all types of application, and be extendable to grow as needed per application. Naturally, any improvements should further contemplate good engineering practices, such as relative inexpensiveness, stability, ease of implementation, low complexity, unobtrusiveness, etc.